home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 130 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.5 KB

  1. Path: fido.asd.sgi.com!austern
  2. From: Dick Menninger <Dick.Menninger@daytonoh.attgis.com>
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Throwing an exception from within a si
  5. Date: 24 Jan 1996 11:36:13 PST
  6. Organization: AT&T Global Information Solutions
  7. Approved: austern@isolde.mti.sgi.com
  8. Message-ID: <DLp9Ez.796@falcon.daytonoh.attgis.com>
  9. References: <4e0moi$4dp@engnews1.Eng.Sun.COM>
  10. Reply-To: mennid <Dick.Menninger@daytonoh.attgis.com>
  11. NNTP-Posting-Host: isolde.mti.sgi.com
  12. X-Original-Date: Wed, 24 Jan 1996 19:13:47 GMT
  13. X-Newsreader: DiscussIT 2.5.1.3 for MS Windows [AT&T Software Products Division]
  14. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  15.     iQBVAwUBMQaKP0y4NqrwXLNJAQEwLgH/Zek/QbNk2aVB3uPwbpAdpXbGvz/Gvqrn
  16.     s5OHj3SE2dNfLiRcixufR+o/Hn5AP+zdI9X1jvVgOb5GGa0pwFj8Qw==
  17.     =S/QG
  18. Originator: austern@isolde.mti.sgi.com
  19.  
  20. > ==========Steve Clamage, 1/22/96==========
  21.  
  22. > In article 8k8@galaxy.ucr.edu, thp@cs.ucr.edu (Tom Payne) writes:
  23. > >Steve Clamage (clamage@Eng.Sun.COM) wrote:
  24.  
  25. > >: What we put in the language standard is binding on all
  26. > implementations. We
  27. > >: try to specify things that can be implemented efficiently on
  28. > any likely
  29. > >: system. In addition, we try to specify features so that they
  30. > have no cost
  31. > >: (or nearly no cost) if you don't use them. IMHO, guarantees
  32. > about what you
  33.  
  34. > >Agreed!!
  35.  
  36. > >: can do in an asynchronous signal handler don't meet those
  37. criteria for
  38. > >: inclusion in the C++ standard.
  39.  
  40. > >That's a rather broad conclusion, given the discussion so far.
  41.  
  42. > I don't agree. If you have control over the entire environment, you can
  43. > make more guarantees about behavior. For example, Ada implementations
  44. > have extensive requirements on what they must support. If a platform
  45. > cannot reasonably meet those requirements, you aren't going to find an
  46. > Ada implementation which is both conforming and useful.
  47.  
  48. > C++, on the other hand, is intended to be dropped into (nearly)
  49. > any existing
  50. > platform and coexist with other languages on that platform.
  51. The language
  52. > definition attempts to stay away from areas where common platforms have
  53. > widely differing behavior for that reason. Asynchronous signal handling
  54. > certainly varies widely among platforms.
  55. > It's easy to wave your hands and say that the implementation ought to
  56. > be relatively easy to do and not overly expensive. But what if the ABI
  57. > on a common platform makes that infeasible? If a language feature
  58. > limits the number of platforms which allow implementation, it should be
  59. > important to a wide range of programmers and programs.
  60.  
  61. It is important for asynchronous threads that may interrupt other
  62. threads (signal handlers, interrupt handlers, ...) to be able to use
  63. the same exception semantics that any thread would use.  Else
  64. you must define two sets of C++ behavior and STL, new, etc., must
  65. all work in both.  You made exceptions part of the language, but
  66. they still seem to be second class citizens.  Until they are made
  67. first class citizens, you will continue to have a lot of arguing about
  68. inherent problems of them being second class.
  69.  
  70. This is just one case where trying to limit the standard to ALL
  71. potential environments seems to be hurting the thinking and
  72. the language.  I suspect that essentially all environments can
  73. actually do something sensible.  If a few cannot, they should
  74. be exceptional, in that area, to the standard.
  75.  
  76. Good Day
  77. Dick
  78. Dick.Menninger@DaytonOH.ATTGIS.COM
  79. ---
  80. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  81.   Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  82.   is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
  83.